Allow custom paths for certificates #36
Conversation
|
@nelfer you might like this change if you still use the container. |
| ## Configure Service | ||
|
|
||
| COPY install/main.dist.cf /etc/postfix/main.cf | ||
| ENV CERTIFICATE_PUBLIC=/etc/postfix/cert/smtp.cert | ||
| ENV CERTIFICATE_PRIVATE=/etc/postfix/cert/smtp.key |
There was a problem hiding this comment.
Can we support inline data here?
For example:
read -r -d '' CERTIFICATE_PUBLIC <<'EOF'
... CERT
... HERE
EOFThis would be able to let me set it in docker cloud web manager directly, without care about any files.
There was a problem hiding this comment.
It would be a bit hacky probably. How would you differentiate between a path and inline data? Because it starts with a /? I would rather use another variable and in the init-openssl.sh echo a CERTIFICATE_PUBLIC_PAYLOAD to the CERTIFICATE_PUBLIC path. Same with private.
It's rare that both CERTIFICATE_PUBLIC and CERTIFICATE_PUBLIC_PAYLOAD be defined at the same time. But I think different variables would end up in cleaner expectation.
There was a problem hiding this comment.
On more thought, is it realistic to manually edit the certificate content? In my use case either in docker cloud or in rancher a letsencrypt container periodically renew the certificate. Been able to mount the output as is in the smf container is enough to keep things working.
If a renewal of the certificate is the motivation for this, it will force you to manually be involved.
And on other side, isn't it to risky to allow save the private key in the database of the docker cloud manager you use?
I think that easy manual editing of the content of the certificate can be obtained by this PR as is plus using for example https://filebrowser.github.io/ which can be used as a docker container and has inline file editing.
| ENV CERTIFICATE_PUBLIC=/etc/postfix/cert/smtp.cert | ||
| ENV CERTIFICATE_PRIVATE=/etc/postfix/cert/smtp.key | ||
|
|
||
| COPY install/main.dist.cf.tmpl /etc/postfix/main.cf.tmpl |
There was a problem hiding this comment.
I'd like to overwrite this file(main.cf) every time if CERTIFICATE_PUBLIC is set because that's the purpose of why we set the ENV variable.
There was a problem hiding this comment.
By default the content of the expanded main.cf will be "overwritten" because the location of /etc/postfix is not mounted as a volume, hence it will be lost between restarts.
But if the user mounts the /etc/postfix/main.cf I don't think is desirable to overwrite it. It's more about not blocking eventual needed tweaks in that file.
|
Hi, @zixia I exposed some concerns regarding your requested changes. Let me know if those thoughts make sense to you. |
|
Hi @bcardiff, sorry for my late reply because I'm kind of busy these days. Before the reply, I think it's better to share my ideas of why I create this SMF project. The goal of SMF project is to make setting up an email forwarder server death easy, as easy as to just set one environment variable and only set one. This variable is named
When we want to support SSL, it's better to just update the certificate files from letsencrypt inside the container right after start, and renew it inside the container, without any additional settings from us. Now if we want to support the custom certificate files, I'm ok with adding the additional environment variables, however, I'd like to keep the fileless mode, we'd better not support a At last, I believe we have to trust the docker cloud service if we are using it because it has the root privileges of our docker host, and certainly, they can read any of the data in our containers without any difficulty. |
|
No worries for the delay @zixia . I understand the original idea of SMF and to be fileless. With this PR that changes slightly due to the expansion of the config file (yet the email queue is also stored in files). Regarding the usage of letsencrypt or other tool generate/renew the certificate automatically, precisely I think this changes are ideal for that. Either in docker cloud or rancher I've used certbot or other docker images with letsencrypt with a mounted volume to store the certificate. The letsencrypt image decides the naming of the final files. So with this PR one is able to mount the same shared volume and specify where to look those certificate files. I don't fully understand how you would use the letsencrypt image in other way without user intervention upon certificate renewal. If you still think the edition of the certifcate content is mandatory to accept the PR and cannot be deferred, lets discus the design since is not something I would actually use (I proposed one here) |
|
|
With this changes using external certificates files is simplified.
The environment variables
CERTIFICATE_PUBLICandCERTIFICATE_PRIVATEdefines the path. The treatment of the certificate has not changed, ie: they will be generated as self signed if the files do not exist.With those variables the user is able to mount the certificates at any place. The integration with letsencrypt wont need a copy step that bothers when the certificate needs to be renewed (every 3 months). Using a symlink could be used as a workaround for sure, but in some scenarios where the access to the host is not available it's a bit problematic.
A dependency to https://github.com/jwilder/dockerize is added to expand the configuration file template to the actual configuration on start up. It's a handy mechanism in many docker images. It could be changed to something simpler, but it works neat. In the expansion of the template the
-no-overwritehelps the user to tweak manually the file if needed.